immutable data model

CRUDのUをしないようにするArchitecture Pattern

そもそも更新がないように設計する

1つのデータに対して、複数の業務から変更が加わると複雑になる

参考

手順化されているのが良い

課題

1つのeventを追加するときの手間が多すぎる

型を定義したり、tableを定義したり

eventに変化が入ったときにmigrationが面倒

dbという外部構造と、entityという内部構造がある時に、

内部構造を変える時に、外部構造を意識しなくてもよくすべき

railsとかみたいに(?)、migration toolがあればいい？

schemaに反映されるclassを変更した時に、migrationすればdbにも反映されるやつ

内部の、eventやstatus型を変更した時に、半自動で過去のDB内のデータを全てmigartionしてくれればいい

パフォーマンス

大量のeventをreduceする際のパフォーマンス

Entityを以下の2種類に分ける

手順

Step1. Entityの抽出

要求文書を書いて、5W1Hに下線を引く

まず要求を自然言語で書いて、entityを抽出するというのが面白い

最初からER図を書くようなことをしてはいけない

その下線部がEntityの属性の候補となる

他の概念の命名に関わるため

Step2. Entityを「Resource(ヒト・モノ)」と「Event(コト)」に分類する

日時を持つかどうかで判断できる

イベントは、Entity名に「〜する」と言えば意味が通る

Step3では「Event」について、Step4では「Resource」について考える

複数の日時属性を持つEntityは分割する

そうするとEvent Entityはimmutableになる

生成された後、更新されることはない

Step4. リソースに隠されたイベントを抽出する

ここで、それらの属性をEvent Entityとして分離することを検討する

それらの属性があると、Resource Entityはどうしてもmutableになる

これをEvent Entityに分離することで、更新頻度を下げることができる

Step5. 非依存関係を交差Entityで表現する

updateがいつ起きるのかを洗い出す

e.g. 会員の情報を変更する

変更した時の情報をちゃんと持たせていないといけない

日時だけでは足りないことがる

例えば、beforeとafterの情報を持っていないと、ロールバックできない

e.g. ユーザーが誤って退会したので戻してほしいと言われた

ので、全部に対して行うのは現実的でない

お金を生み出すもの、記録が残っていないとお金を失うリスクがあるもの、に限って実践する

悪い例

以下のようなルールが必要になる

データ型だけ見て、ルールの存在を認識できない

各ユースケースの設計書で説明を書かないといけない

Event Entityは1つの日時属性だけ持つ

変更日時と登録日時は常に同値になるので別々に持つ意味がない